The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
docs	Skipped			Nov 10, 2025 11:51pm

Greptile Overview

Greptile Summary

This PR adds a visual indicator when a child workflow referenced in a workflow block has been modified since its last deployment. It introduces a needsRedeploy flag that compares the workflow's updatedAt timestamp with the active deployment's createdAt timestamp. When changes are detected, the badge changes from green "deployed" to orange "redeploy" and becomes clickable to trigger redeployment.

Key changes:

• Added parallel API fetching for deployment versions and workflow metadata in use-child-deployment.ts
• Implemented timestamp comparison logic to detect when workflow changes require redeployment
• Updated UI to display orange "redeploy" badge with clickable action when redeployment is needed
• Maintains existing deployment functionality while adding improved workflow state visibility

Confidence Score: 4/5

• This PR is mostly safe to merge with minimal risk of breaking existing functionality
• The implementation is straightforward and well-structured, introducing a new feature without modifying core deployment logic. Parallel API fetching improves performance. The timestamp comparison logic is sound since both timestamps come from the database. However, the confidence is 4 (not 5) due to one consideration: the timestamp comparison doesn't account for timezone differences or clock skew, though this is unlikely to cause issues in practice since both timestamps are from the same database server
• Pay attention to use-child-deployment.ts - the timestamp comparison logic assumes database timestamps are consistent and monotonic

Important Files Changed

File Analysis

Sequence Diagram

sequenceDiagram
    participant UI as Workflow Block UI
    participant Hook as useChildDeployment
    participant API1 as /api/workflows/{id}/deployments
    participant API2 as /api/workflows/{id}
    participant DB as Database

    UI->>Hook: Mount with childWorkflowId
    Hook->>Hook: fetchActiveVersion(childWorkflowId)
    
    par Parallel API Calls
        Hook->>API1: GET /deployments (fetch active version)
        API1->>DB: Query deployment versions
        DB-->>API1: versions with createdAt
        API1-->>Hook: {versions: [{version, isActive, createdAt}]}
    and
        Hook->>API2: GET /workflow (fetch metadata)
        API2->>DB: Query workflow
        DB-->>API2: workflow with updatedAt
        API2-->>Hook: {data: {updatedAt}}
    end

    Hook->>Hook: Compare timestamps:<br/>needsRedeploy = workflow.updatedAt > deployment.createdAt
    Hook-->>UI: Return {isDeployed, needsRedeploy, activeVersion}
    
    alt needsRedeploy is true
        UI->>UI: Show orange "redeploy" badge
        Note over UI: Badge is clickable
        UI->>UI: User clicks badge
        UI->>API2: POST /api/workflows/{id}/deploy
        API2->>DB: Create new deployment version
        DB-->>API2: New deployment with new createdAt
        API2-->>UI: Deployment success
        UI->>Hook: refetchDeployment()
        Hook->>Hook: Increment refetchTrigger
        Note over Hook,API2: Repeat fetch cycle
    end

• This PR is mostly safe to merge with minimal risk of breaking existing functionality
• The implementation is straightforward and well-structured, introducing a new feature without modifying core deployment logic. Parallel API fetching improves performance. The timestamp comparison logic is sound since both timestamps come from the database. However, the confidence is 4 (not 5) due to one consideration: the timestamp comparison doesn't account for timezone differences or clock skew, though this is unlikely to cause issues in practice since both timestamps are from the same database server
• Pay attention to use-child-deployment.ts - the timestamp comparison logic assumes database timestamps are consistent and monotonic

The timestamp comparison is safe because deployWorkflow explicitly does not update
workflow.updatedAt (only sets isDeployed and deployedAt), while
saveWorkflowToNormalizedTables always updates updatedAt on any change. This means
updatedAt > deploymentCreatedAt reliably indicates workflow changes occurred after the
last deployment, with no risk of false positives